Currently, in order to remain successful, organizations need to react quickly to changes in their business environment in order to take advantage of opportunities in the marketplace and to stave off competitive threats. The change could be due to any number of internal or external factors; however, whatever their cause, organizations need to be able to rapidly change their business processes effectively and efficiently in response to such a change. Changing business processes also requires changes to business policies, the training of business users and end users, and of the business applications that support those business processes and policies.
Presently, business applications (e.g., ERP, SCM, CRM, etc.) are not flexible to include configuration options to support changes in business processes. Consequently, often times organizations end up with sub-optimal solutions to address their problems (e.g., a system work-around may be employed, or applications code may be “customized” to support the organizations business needs, or worse still the business process may be adapted to fit what can be supported by the application). These approaches are not easily supportable and incur additional costs on the organization.
Furthermore, business processes within an organization can span many disparate applications from different vendors/suppliers and on different platforms and legacy systems. That is, a business process may require an output, data or result of a business function from one system or module to feed into the input of a business function of another system or module. This makes it all the more difficult to meet the organizations need for agile business applications since the systems from the disparate vendors need to be interoperable.
Some of these problems are starting to be alleviated with the use of Services and Service Orientated Architecture (SOA). Using SOA applications functionality from disparate vendors can be “exposed” as services and “orchestrated” (using orchestration capabilities like Business Process Execution Language (BPEL)) into new composite applications. These composite applications can be developed to support an organization's business processes. The services are “exposed” using industry standard protocols so that they are interoperable and using the appropriate tools can be more readily orchestrated.
Although using Services and SOA permits organizations to assemble their own composite applications to better support their own business processes, the following problem areas remain: 1) How to provide an effective (and agile) help system for users of the composite application, 2) How to provide effective (and agile) defect tracking for the composite application, and 3) How to create an effective (and agile) knowledge base for supporting the composite application. In effect, when an organization creates a composite application (potentially from different vendors and on different platforms), the organization is creating a new, and potentially unique, composite application that is not supported by any one vendor and must be supported by the organization itself.
It is given that each application service that is “exposed” by a vendor, would be supported in the same way that one would expect a vendor to support their published APIs (application programming interface). However, an organization that creates a composite application is responsible for the support of the resulting composite application itself, and the greater the number of services that an organization uses from different vendors and or legacy systems, the more complicated the support issues become.
Hence, the IT department of an organization or a system integrator on behalf of the organization, would be required to “hard code” user help system for the components that comprise the composite application. The disadvantage of hard coding the user help is that it will need to be re-coded for every change of the components that comprise the composite application. A further problem occurs when the composite application is deployed and issues are encountered by end users that result in the user requiring support from the organization's IT helpdesk. By creating a composite application the organization must now support any user issues that arise. Therefore, there is a need to capture defect information and sufficient details of the composite application and the composite application's components in order to provide an effective knowledge base of issues and their solutions such that the IT Helpdesk can triage and support any issues that arise.
Further, as new components are added or modifications are made to existing components of the composite application, it becomes difficult to keep track of the configuration of each of the components that comprise the composite application consequently any knowledge base can quickly become outdated and the burden of support by the organization increases with time. Hence, for these and other reasons, improvements in the art are needed.